PSBT: Add pay-to-contract tweaks to tx inputs #1239
Conversation
A number of protocols utilizes pay-to-contract and/or sign-to-contract public key tweaks. Inclusion of the tweak information into outputs (for pay-to-contract) or inputs (for sign-to-contract) as a security measure requires presence of full information from which the tweak is generated, i.e. protocol-specific and SHOULD not be a part of this standard. However, to spend already existing output containing pay-to-contract commitment a signer must apply raw tweak value to the private key. This operation is safe even if the meaning of the tweak is unknown since it does not provides any commitment to any external data. Since this operation is not protocol-specific I propose to add standard fields in order to provide signers with necessary information.
|
See also https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2019-March/016713.html where I proposed something like this and achow gave me a concept ACK, but I then did not follow up on this (except for the Miniscript-related fields). |
|
In accordance with https://github.com/bitcoin/bips/blob/master/bip-0174.mediawiki#procedure-for-new-fields, these fields should first be proposed on the bitcoin-dev mailing list |
| | 174 | ||
| |- | ||
| | Taproot Internal P2C Tweak | ||
| | <tt>PSBT_IN_INTERNAL_P2C_TWEAK = 0x1b</tt> |
There was a problem hiding this comment.
The difference between this and PSBT_IN_TAP_P2C_TWEAK is not clear to me. ISTM this is for the internal key specifically, but the same effect can be achieved by specifying the internal key in PSBT_IN_TAP_P2C_TWEAK.
There was a problem hiding this comment.
Agree, good point
| | Taproot Per-key P2C Tweak | ||
| | <tt>PSBT_IN_TAP_P2C_TWEAK = 0x1a</tt> | ||
| | <tt><xonlypubkey></tt> | ||
| | 32 bytes of public key specifying to which of keys tweak must be applied (i.e. this MUST be a value of a public key before the tweak is applied) |
There was a problem hiding this comment.
Does there need to be any consideration for keys in leaf scripts?
There was a problem hiding this comment.
I expect this to be a bad practice: the commitment must be singular per output (for instance to prevent double spends in second-layer systems like RGB), so allowing multiple tweaks in the same output is a security risk.
There was a problem hiding this comment.
I would like to support keys in leaf scripts (and arbitrary numbers of tweaks on arbitrary sets of keys). If the possibility is a security risk for some other protocol there is nothing that PSBT can do about it.
There was a problem hiding this comment.
Ok, probably I was overcautious.
Actually there is no risk in spending P2C output, since the commitment is produced not at the spending time.
There was a problem hiding this comment.
@apoelstra what do you mean by "tweaks on arbitrary sets of keys":
- the same tweak must be applied to each of the keys in the set;
- the tweak must be applied to one and only one key (i.e. the sum of this keys commits to the tweak)?
There was a problem hiding this comment.
I came to conclusion that even most complex cases can be covered by a quite simple setup - pls see my description in https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-January/019761.html
|
I will write a proposal to bitcoin-dev taking @apoelstra as a starting point over the holidays - and after discussion there will update this PR |
|
BIP 174 is Final... should be a new BIP (or maybe part of PSBTv2 if it's not done?) |
|
@luke-jr BIP-174 allows adding new fields in a backward-compatible manner:
The procedure for adding new fields is the following:
from this follows that new fields should be to be added both as new separate BIP and to the table in this BIP-174, with a reference to a dedicated BIP (like it was done for the taproot and hash preimage keys). |
|
Updated proposal posted to bitcoin-dev mail list: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-January/019761.html After discussion there I will update this PR with the proposal |
|
@apoelstra, @achow101 did a PR here with a new BIP proposal #1293. |
|
Can this PR be closed? |
|
I assume once #1293 will get merged this one still to be added to the main PSBT BIPs (I will update it then) |
|
The PR #1293 has been merged. What’s the status of this PR? |
|
Will update next week. |
murchandamus
added
the
PR Author action required
|
Pinging @dr-orlovsky for update. |
|
I am closing this pull request, because it has not made progress in over two years since the prerequisites for further steps had been met, and two requests for updates six and three months ago have been outstanding. If you are still working on this project, please request reopening or open a new pull request. |
A number of protocols utilizes pay-to-contract and/or sign-to-contract public key tweaks. Inclusion of the tweak information into outputs (for pay-to-contract) or inputs (for sign-to-contract) as a security measure requires presence of full information from which the tweak is generated, i.e. protocol-specific and SHOULD not be a part of this standard. However, to spend already existing output containing pay-to-contract commitment a signer must apply raw tweak value to the private key. This operation is safe even if the meaning of the tweak is unknown since it does not provides any commitment to any external data. Since this operation is not protocol-specific I propose to add standard fields in order to provide signers with necessary information.
Looking for Concept ACK and I will add to the PR changes to other PSBT-related BIPS and more information on the tweaks.
CC @achow101